Thread: [ISO] Notation for mathematical intervals

Under ISO 31-11, I could write ]2,5[ or (2,5). Both square brackets and parenthesis were accepted symbols for open ends on either side of the interval.

However ISO 80000-2:2009 supersedes it and I can't seem to find any reliable access to the text. Do you know if this remains the case in the new ISO?

Make them UDTs, overwrite their logical operators and write something more beautiful, like:

return (a < x < b);

Or don't.

Also, that typedef is hurting my eyes.

Make them UDTs, overwrite their logical operators and write something more beautiful, like:

O_o

You'll find that a bad idea. The C++ language has no way to express differentiation of a boolean context from an arithmetic context without transforming the expression into a type.

*shrug*

Anyways, I found what I could of your other threads. (I refuse to sign a forum I'm not interested in actively participating.) I have to ask, why do you want to use the bracket form so much? I don't care. I'm just curious why the parenthesis is unacceptable?

To be honest, I'm also wondering why you couldn't use a markup of some sort allowing the reader to use whichever form with which they are most familiar.

Soma

Templates would be cool but the problem is, they allow any​ type (like char or bool).

O_o

Rubbish. If an expansion is invalid, you can blacklist the relevant types.

*shrug*

You could just whitelist `float`, `double`, and `long double` types if you can only use something like real numbers.

Soma

Originally Posted by phantomotap

Anyways, I found what I could of your other threads. (I refuse to sign a forum I'm not interested in actively participating.) I have to ask, why do you want to use the bracket form so much? I don't care. I'm just curious why the parenthesis is unacceptable?

During my early days, I learned with the brackets form. So parenthesis look as weird to me as the brackets do to you. During my undergrad days I started to gain access to Anglo-Saxon texts and I realized you used parenthesis, while Latin countries tended to use the brackets. It seems to be (or have been at some point) a cultural thing.

I'm not much concerned which one I use. As long as it is well defined. It's just that I was having a discussion with a colleague of mine that insisted the new standard removed the brackets form. Since I do teach college mathematics and I tell my students of both forms, I'd like a confirmation this is the case.

Did get an answer somewhere else. Both forms remain.

Originally Posted by phantomotap

You'll find that a bad idea. The C++ language has no way to express differentiation of a boolean context from an arithmetic context without transforming the expression into a type.

I'm most definitely rusty of my C++, but wasn't it possible to chain boolean operations?

[Edit]
Overshoot.

*sigh*

Yes. You can chain virtually any operator for a custom type, but the result of chaining operators returning a boolean value doesn't do what the expression implies you expect because each new link in the chain only results in a boolean value.
[/Edit]

I'm most definitely rusty of my C++, but wasn't it possible to chain boolean operations?

O_o

Yes. In fact, you'd have to overload one such operator for the differentiation to work.

The problem is that, without transforming the expression into a type, none of `operator bool()`, `bool operator < (UDT, UDT)`, or `UDT operator < (UDT, UDT)` are aware of which you want to call in the context of the proposed expression which means that simply overloading those operators produces unexpected results. You can't even have both forms of the comparison operator. (You'd find the expression ambiguous, so compilation would not be successful, if you could have both forms.) You have to choose how the fragment `a < x` behaves in the context of the proposed expression or change the types of the parameters.

The `bool operator < (UDT, UDT)` form returns a value unrelated to the input with respect to the expression leaving you with a `true < b` fragment or a `false < b` fragment. You could overload `bool operator < (bool, UDT)` which allows the chaining, but you've lost the input value so have no way of comparing to the limit.

The `UDT operator < (UDT, UDT)` form returns a value of type `UDT` which allows chaining while propagating the relevant value. The chaining calls the same form of the operator, but you don't want a value of type `UDT` for the `UDT < b` fragment. You want a boolean result from the `UDT < b` fragment. You could overload the `operator bool` or similar method, but you've not stored the result of the comparison so whatever you return isn't related to the relationship between `this` and the `b` value. Of course, you could store the result of the comparison; you'd have to modify the input for a comparison function which is rather stupid.

You need to propagate the relevant values and the result of comparison in the fragment `a < x` for the expression `a < x < b` to have the intended semantics. You can store the values and the result in infinitely many ways, but you'll eventually wind up with some `UDTComparisonResult` which has the relevant `UDTComparisonResult operator < (UDTComparisonResult, UDT)` and `operator bool` overloads.

*shrug*

Personally, I'd go with the logically combined form rather than play games with types and operators.

o_O

Well, I've done exactly that for practice. I don't use such a thing in real code.

Soma

Isn't it a math thing and not a culture thing?

O_o

You'll find that `]0, 1[` is different than `[0, 1]`.

How would I go about doing something like this?

You've been shown examples, by more than just me, of how to place limits on the acceptable types.

I suggest you study the examples.

Soma

Originally Posted by MutantJohn

Isn't it a math thing and not a culture thing?

I explained why it isn't a "math thing" in post #1.

Both forms are acceptable. The question was only if the new standard that supersedes the old one, this was still the case. And it still is.